Chapter 5: Changes

 

Changes are objects that drive the Lifecycle and revision of items. Changes are routed through workflows for approval and only come into effect if they reach an approved workflow status. There are several types of changes (note that your administrator may have created new subclasses or changed the notation in your 4G:PLM installation):

5.1 Change Types

5.1.1 Engineering Change Order (ECO): It is used to create a new revision of an item. Anything on the item can be modified.

5.1.2 Manufacturing Change Order (MCO): Does not create a new revision of an item. Can only modify the AML list or a restricted set of attributes.

5.1.3 Engineering Change Request (ECR): An engineering change request (ECR) is used to describe a suggested enhancement or problem with a product. The form initiates the change process — it promotes discussions within the organization to help determine the impact of a change and the best possible solution.

5.1.4 Deviation: Does not change an item. It is used to record deviations from standard in manufacturing.

5.1.5 Stop-ship: Does not change an item; it is used to model the emergency situation where a manufactured item’s shipping should be halted, pending further action.

5.2 Create ECO
An engineering change order (ECO) is a documentation packet that outlines the proposed change, lists the product or part(s) that would be affected and requests review and approval from the individuals who would be impacted or charged with implementing the change. ECOs are used to make modifications to components, assemblies, associated documentation and other types of product information.

Let’s create an ECO and use it to release any part. Assume that we have created a new part which is in Preliminary LifeCycle phase and has Revision New. To create a new ECO, click on the Change link on the Part or click on New Object and select ECO




A new ECO form will pop-up. Use the dropdown to select Change Type. Click on the Create button.




ECO number will automatically filled which can be over-written. Finally, click on the Create button to create ECO.




Once the ECO is created, it is in unassigned phase. The Affected Items is blank as 4G:PLM automatically doesn’t create the reference with Part. We need to manually add the Affected Item to the ECO. It can be done using the drag and drop functionality or through the Add button.




Let us add the newly created Part to the ECO. Once the Part is added to the ECO, it would show-up in the Affected Item tab. The Affected Item automatically shows the Prior LifeCycle Phase, Proposed Rev, Proposed LifeCycle Phase of the added Part among other information.




The ECO is still in the unassigned phase, we need to assign workflow to the ECO and fill required information in the ECO details tab. The workflow can be configured the system administrator. The dropdown will list all the workflows and based on the defined workflows, it would have different workflow phases.




Next, we need to assign a Change Analyst to the ECO. Change Analyst is responsible for driving the whole process and responsible to bring it to closure. The workflow and Change Analyst once selected cannot be changed.




Change Analyst is responsible for monitoring the process of the change through its workflow, tending to it if it becomes stuck (nobody approves or rejects) or moving it to the next step in the workflow if auto-promote hasn’t been activated by the administrator for the workflow. Clicking on the “Change” button next to “Change Analyst” displays a list of people to choose from (people who may act as change analyst is determined by membership in an administrator-defined group):




Now, when we go to the Workflow tab, we can see ECO has workflow assigned to it. The default workflow phase is in Pending




To move to the next workflow phase, click in the box. For example, to move the ECO to the Submit workflow phase, click on the Submit box




In this dialog, you need to select an authorized approver and optionally additional observers, who should be informed of the ECO’s progress but cannot influence it directly.



After doing this, you can see the small red triangle is now just before the next step in the workflow, “Submit”. Note that you can always double-click on the special “Cancel” state to end a workflow, or on “Hold” to put it on hold, if the administrator has allowed these states. If you have the appropriate permissions, you can double-click on any state to advance the change to that state directly.

In this case, we have set ourselves as approver, so the “Approve” and “Reject” buttons become active. If we approve, we see the workflow move to the next step:




Note also that all actions are recorded in the activity log. Now, the ECO can be moved step by step through the workflow by using a series of “Promote” and “Approve” actions. The states in this sample workflow have the following meanings:
         
·    Pending: The change has been newly created and added to a workflow, but nobody is actively working on the workflow.
          ·    Submit: The change has been submitted and people involved have been notified.
          ·    Review / Approval: An initial review step to approve moving the change forward.
          ·    CCB: Change Control Board: stakeholders vote on whether to approve the change.
         
·    Released: The change has been approved. The new revision becomes the current revision.
         
·    Implemented: The change has been carried out in manufacturing.

We can now go to the Affected Items tab and update the Revision of the Part and also the LifeCyle phase




Once we have Save the changes, we can now release the Change by going to the Workflow tab. Clicking on the Release button will ask if you would like to Release the ECO.




Clicking on the Release button will ask if you would like to Release the ECO.




The Affected Item tab will show the Rev as 1.0 and LifeCycle Phase as Prototype.




If we go to the Part, we can see the Rev as 1.0 and the Part LifeCycle now show as Prototype.




If we go to the Changes tab, we can see all the Changes related to the Part. Please note all the unreleased Changes would be shown within parenthesis

 

5.3 Create MCO
A manufacturing change order (MCO) functions in the same way as an engineering change order (ECO), but the revision of the affected item cannot be changed, nor can the bill of materials (BOM) be altered in any way. Moreover, attributes subject to change control (which normally includes most of them) cannot be changed except with an ECO.
The MCO is u
sed to do one of three things:
          1.    Change the lifecycle of an item.
         
2.    Change attributes not subject to change control.
          
3.    Modify approved manufacturer data (AML data)

Note that although there is no red-lining of a BOM with an MCO, changes to the AML data are tracked as red-lines, just as with an ECO.

The affected items tab of an MCO displays for information the item number, item description and old lifecycle. There should be a field for the new lifecycle, which is editable. No other fields are necessary for editing.



As with an ECO, an MCO applies always to the latest released revision of an affected item.

5.4 Create Deviation
A deviation is used to indicate some temporary change in the manufacturing of an item. Consequently, it requires two fields on the cover page:
          ·     “Effective from”
          ·     “Effective to”



These are both date fields. If a deviation is valid from 05.02.2014 to 28.02.2014, then the “Effective from” field would be set to “05.02.2014” and the “Effective to” field to “28.02.2014”. No deviation can be released unless both of these fields are set.

The workflow of a deviation must contain a status of type “Released”. When this status is attained, the deviation is regarded as being in effect (if the “Effective to” date has not been exceeded). Once the “Effective to” date is exceeded, then the workflow should be advanced automatically to the next workflow state, which should be one of type “Complete”, and may bear a name such as “Expired”. It should also be possible to promote the deviation manually to the next state (as with any normal change order).

The affected items tab of a deviation should show for information the item number, description and lifecycle phase of the affected items. The revision should be selectable, but default to the current revision.

By default, a deviation should apply to the most recently released revision of an affected item, but the user should be able to choose a different revision.

 

5.5 Create Stop Ship
A stop-ship indicates that the affected item should no longer be shipped. This usually occurs due to some manufacturing quality problem that is discovered and must be analyzed. No alterations of the affected items are possible with a stop-ship.
When a stop-ship enters a workflow state of type “Released”, this signifies that the affected items should not be shipped. The final state in a workflow for a stop-ship should be of type “Complete”. This signifies that it is safe to ship the affected items again.
The affected items tab of a stop-ship cannot be used to change anything, so informational (read-only) fields should be shown for the item number, description and lifecycle. The revision field is selectable, but defaults to the current released revision.



As with deviations, a stop-ship should apply by default to the current released revision of an affected item, but the user should be able to specify an earlier revision, if desired.

 

5.6 Engineering Change Request
An engineering change request (ECR) is not used to change any item information; rather, it is a means for users to request that an engineering change, usually an ECO, be issued. This is useful because often the number of people with permission to create change orders is restricted, but a larger circle of people, e.g. from manufacturing, may wish to request changes.
Although it cannot change any item data, it is very similar in structure to a change order in that it goes through a workflow, must be assigned to a change analyst and has affected items. The affected items tab, however, shows only read-only fields for item number, description and lifecycle. The revision is also shown and is selectable, but defaults to the current revision.
When an ECR is released, it is the responsibility of the releaser to create an ECO manually. No automation is required for Release 1.0 of 4g:PLM.